Developer CD Series 2000 January: Mac OS SDK

home *** CD-ROM | disk | FTP | other *** search

/ Developer CD Series 2000 January: Mac OS SDK / Dev.CD Jan 00 SDK1.toast / Development Kits / Mac OS / Multiprocessing 2.0 SDK / Documentation / Multiprocessing FAQs < prev next >

Wrap

Text File | 1999-08-30 | 12.1 KB | 313 lines | [TEXT/MSIE]

<HTML> <HEAD> <TITLE>Multiprocessing FAQs</TITLE> <META NAME=GENERATOR CONTENT="Claris Home Page 2.0"> <X-CLARIS-WINDOW TOP=52 BOTTOM=561 LEFT=118 RIGHT=648><X-CLARIS-TAGVIEW MODE=minimal> </HEAD> <BODY BGCOLOR="#99CCFF"> <H1><CENTER>Multiprocessing API - Frequently Asked Questions </CENTER></H1> <P><CENTER>Last updated: 8/03/99</CENTER></P> <P> </P> <H2>What is multiprocessing and multitasking?</H2> <P>Multiprocessing is the use of more than one processor (CPU) simultaneously. By definition only a machine with more than one CPU is capable of multiprocessing. Multitasking allows multiple streams of execution to be created even if there is only a single CPU. The MP API implements a multiprocessing and multitasking environment. Any number of streams of execution can be created and one stream per CPU can be executing at any particular instant in time. Each stream of execution is called a task. Having concurrent tasks working on parts of some job, e.g. a ray trace, an image filter, a fractal etc., can reduce the overall time it takes to complete the job.</P> <P> </P> <H2>What is the MP API?</H2> <P>The MP API allows a programmer to create tasks and to establish communication between them and the main application's cooperative task. A small number of other services are also available. The Multiprocessing.pdf document describes these services in detail.</P> <P> </P> <H2>What is the Multiprocessing API Library?</H2> <P>The Multiprocessing API Library is a shared library that provides the services defined in the MP API. The Multiprocessing API Library communicates with the integrated task scheduling facilities and other task related issues. The library and its associated files are usually installed in the extensions folder.</P> <P>NOTE: As of the Mac OS 8.6, the Multiprocessing API Library has been intergrated into the system file and no longer ships as a seperate library to be installed in the extnesions folder</P> <P> </P> <H2>Why am I getting an "out of memory" warning after the Finder starts?</H2> <P>If you get this message, you are running with the old v1.4 Multiprocessing API Library. The new integrated v2.0 library has eliminated the out of memory problems. It is no longer necessary to modify the Code Warrior extension MetroNub to increase its memory requirements.</P> <P> </P> <H2>What can tasks do?</H2> <P>In general tasks can execute any function accessible by your application. Tasks created using the MP API have the ability to access main memory allocated by any tasks created by the main application and to communicate with other tasks as well as the application. Tasks must adhere to the restrictions outlined below. </P> <P> </P> <H2>What are the restrictions on tasks and the application?</H2> <P>Tasks must not execute 68k code. Attempting to do so by calling through a UPP that entails a mixed mode switch to 68k will cause the task to be terminated.</P> <P>Tasks must not call the Macintosh Toolbox directly. Tasks can access toolbox functions via the MPemoteCallfunction.</P> <P>The application must not make MP API calls at interrupt time or from within a deferred task other than those specifically defined as interrupt-safe in the MP API documentation. Note that deferred tasks are defined in the Deferred Task Manager, they are not an MP API related concept.</P> <P> </P> <H2>How are tasks run?</H2> <P>Preemptive tasks, along with the Mac OS (blue) task, are inserted into a scheduling queue and are assigned to available processors. Tasks run preemptively. They run for a certain amount of time after which they will be interrupted and returned to the end of the scheduling queue. This way all tasks in the system can be assured fair access to the available processors. Tasks can also voluntarily return themselves to the scheduling queue using the MPYield() call. When a task blocks on one of the resource objects, and that resource is not available, the task is immediately suspended and the next task on the scheduling queue is run. Suspended tasks are not returned to the scheduling queue until the object on which they are waiting becomes available. Suspended tasks incur no system overhead.</P> <P> </P> <H2>How many tasks should I create?</H2> <P>The number of tasks an application can create is not logically limited. Most applications will want to limit the creation of tasks that perform a given function to the number of available processors. As long as there are at least as many tasks performing work as there are available processors, maximum advantage of the system will be taken. Some problems are best decomposed into a fixed number of tasks, regardless of the number of processors. It is sometimes useful to have the main application perform some of the work also. This is especially true in applications that do not require the Multiprocessing API Library to be present. In this case the optimum number of tasks to create is the number of processors.</P> <P> </P> <H2>Do I need a multiprocessing system to use the MP API?</H2> <P>No. The Multiprocessing API Library is always available. This means that you can create preemptive tasks on a PowerPC platform, provided those tasks adhere to the restrictions described above.</P> <P> </P> <H2>What special tools do I need for development?</H2> <P>You continue to use the same development tools you have always used. There are no special compilers or linkers to be used. All you add is a header file, Multiprocessing.h, to your source code then include the MPLibrary.stub file in your linker library list.</P> <P> </P> <H2>How do I debug this stuff?</H2> <P>Macsbug is capable of debugging tasks much in the same way as it debugs within Mac itself. In addition, the MP API has debugging functions that let you write a high level debugger. <I>Metrowerks has an MP debugger that needs to be qualified in this release.</I></P> <P> </P> <H2>How can I test MP-savvy applications?</H2> <P>Apple recommends testing the MP-savvy applications on two platforms: a uniprocessor Macintosh and a multiprocessor Macintosh. The application code can be identical in both cases, but the application may have dependencies or race conditions that are only visible on a multiprocessor system.</P> <P> </P> <H2>When can I get started?</H2> <P>You can start now. The Multiprocessing API Library and multitasking enabler included on this disk is the final product. It will allow you to create and test applications on uniprocessor systems that will run without modification on real multiprocessing systems (assuming no programming errors of course).</P> <P> </P> <H2>When will hardware be available?</H2> <P>Hardware is available now in 9500/180MP systems and DayStar Genesis 2-P systems. Other system configurations will be available soon.</P> <P> </P> <H2>How will supporting the MP API impact my source base? What about 68K?</H2> <P>The MP API cannot be used on 68k machines. You can have a single source base but the 68k side will not be able to create preemptive tasks -it should behave as though the Multiprocessing API Library is not present. The PowerPC side should also be able to handle the situation where the Multiprocessing API Library is not present even though it is now a permanent part of the system. This retains backward compatibility. The same code can thus be used for both situations.</P> <P>If an application requires PowerPC and is also willing to require the presence of the Multiprocessing API Library, then tasks can be created and executed regardless of the number of processors in the system. Tasks created by an application are distributed preemptively amongst the available processors, even if there is only one, so task-creating code will work on any type of PowerPC system.</P> <P> </P> <H2>What will happen to the MP API when Carbon API ships?</H2> <P>The MP API will run on all current and planned generations of the PowerPC-based Mac &emdash;namely, Mac OS 8, the Carbon API under Mac OS 8, and in Mac OS X.</P> <P> </P> <H2>How are the MP API and the Thread Manager related?</H2> <P>MP tasks are preemptive execution streams, and are implemented as kernel tasks in Mac OS 8 and Mac OS X. The task and thread APIs will remain different.</P> <P>The Thread Manager API will definitely be supported in Mac OS 8 and Mac OS X, but there are no plans to extend it. Threads will continue to have the same cooperative scheduling model. Threads are not the path to preemptive scheduling or multiprocessor support in Mac.</P> <P> </P> <P>We are recommending that developers use the MP API to write applications that wish to take advantage of preemptive scheduling and multiprocessors, both on Mac OS 8 and Mac OS X. This API is fully supported in Mac OS 8, and beyond. It has been designed to map naturally into the Mac OS X tasking model. In Mac OS 8 and Mac OS X, MP tasks become identical to kernel tasks, The MP APIs become thin layers of glue mapping them into kernel calls.</P> <P>The "MP" API is probably misnamed because it is supported on all Power Macintosh systems, both uniprocessor and multiprocessor. An application written to the MP API will automatically take advantage of all processors that are available. On uniprocessor systems, MP tasks behave like preemptive tasks.</P> <P> </P> <H2>Where can I find examples?</H2> <P>In this SDK! </P> <H2>How can I communicate with a task at interrupt time or from within a deferred task?</H2> <P>With the v2.0 integrated multitasking support, communication can be achieved by simply using the SetEvent, SignalSemaphore, or MPNotifyQueue functions. The SetEvent and SignalSemaphore functions are always interrupt safe. MPNotifyQueue becomes interrupt safe when the subject queue has had notifications reserved for it. See MPSetQueueReserve in the MP API documents for details.</P> <P>The rest of the Multiprocessing API Library is not interrupt safe and any attempt to call it at interrupt time or deferred task time will potentially cause a crash.</P> <P> </P> <H2>What kind of problems can I expect from tasks sharing memory? </H2> <P>Tasks should be careful about what memory they modify -it is not polite to modify memory being used by another task without communicating that fact to the other task. Modifying globals from within a task, or buffers pointed to by global variables should be avoided.</P> <P>Tasks must not attempt to modify memory outside of the application address space. Although implementations may vary, the model is that each application runs in its own address space. The application's cooperative task (and threads), and any preemptive tasks created by the application share the same address space. Although the current Mac OS 8 implementation has all applications running in a global address space, this may change at any time. Applications that expect to run unchanged in Mac OS X must not violate the memory model.</P> <P> </P> <H2>I crash after calling MPTerminateTask(). Why?</H2> <P>MPTerminateTask() does not terminate a running task immediately. The task may continue to run for a short time while termination proceeds asynchronous to the MPTerminateTask call. Normal application cleanup techniques involve terminating all the tasks owned by the application and then disposing of all the semaphores, queues, memory, etc. that the tasks were using. Since the task doesn't really stop running straight away it starts using invalid data as the application starts deleting the shared resources. This can lead to catastrophic crashes. The proper way to avoid this situation is to provide a termination queue when you create a task, and wait on the queue immediately after terminating the task. Once something is received you can be sure that the task is no longer running. Alternatively your application can notify a task that it is about to be terminated and wait for the task to acknowledge the notification. The task should not use any more shared resources after it sends the acknowledgment.</P> <P> </P> <H2>How do I get support for the MP API?</H2> <P>Apple computer is providing support for the MP API. You can contact Apple at dts@apple.com .</P> <P> </P> <P> </P> <P>Copyright © Apple Computer, Inc.</P> </BODY> </HTML>